In order to make dynamic systems behave as required, the users and operators of such systems can use a set of policies that specify how the system should respond to various situations. Each policy or policy statement applies to a specific application or a set of applications, and may be specific to a logical instance of the application. It may describe a condition and a network service to be applied for traffic matching that condition. A policy statement may comprise a general Boolean expression of its underlying policy conditions. Each condition describes a subset of traffic flows of the application and may comprise basic condition components, each comprising a basic policy parameter identifier, an operator and operand. Policy identifiers may be application-specific. Each policy identifier may have a pre-defined type such as string, integer, or enumerated value. For example, a policy identifier may be “URL”, an operator may be “contains”, and an operand may be “www.nokia.com”. A plurality of global, pre-defined policy identifiers may include source and destination Internet Protocol (IP) address, source and destination port numbers, protocol, application identifier, and an application code point (ACP) which may identify and define one or more types of traffic flows or classes that are produced by an application or may define application flows in a static manner, for example, according to intrinsic application parameters.
The overall mechanism then consists of the configuration and management of the policies (human interface of the policy control mechanism), and the resolution and enforcement of the policies (automated part of the mechanism). The policy resolution and enforcement applies the configured policies by first receiving as input a trigger event that initiates the resolution of a policy, and then sending as output instructions that enforce the outcome of the resolved policy action.
The trigger events and policy actions can generally be described as state changes. Trigger events are already happened state changes that are received as inputs, while policy actions are state changes that should happen in the future, and are for that purpose sent as outputs. The actual detection of trigger events and effecting of changes specified by the policy actions can be considered to reside in components outside of the policy control mechanism.
Because both trigger events and policy actions are state changes with only difference being their timing and probability (1 for trigger events, <1 for policy actions), the conclusion is that some policy actions can become trigger events for subsequent policies. There is a unidirectional causal relationship between the two, where one state change can be traced backwards or forwards to another state change. This makes policy I/O different from generic I/O in e.g. software.
One example of policy control area is multi-access, which means a situation where a device has multiple interfaces, logical accesses and connected network domains over which it has connections and traffic flows. The device can have access over these multiple networks sequentially or simultaneously, and policies are needed to describe which connection is acceptable over which network, as well as whether it can or should be moved to a new network.
An example of the policy resolution is when a trigger event such as a detection of an interface losing connectivity to a network causes the policy action of attempting detection of a new network with a different interface, joining the new network and then moving all traffic to it from the previous network. The policies involved in this task easily become very complicated, and multiple trigger events can be received during very short periods of time. The policy actions may also become available for sending as outputs at different times, because resolution of some of them consists of more steps and takes more time than for the others. This may lead to resolution delays, e.g. when the resolution engine first receives a trigger event telling it that a new flow has been initiated and selects a suitable network for it; and immediately afterwards receives a trigger event telling that the network has become unavailable, meaning that the resolution engine needs to select a new network. Additionally, looping and oscillation in terminal connectivity may occur, e.g. when the resolution engine first receives a trigger event telling it that a flow has been closed and disconnects from that access network because there are no more flows using it, and immediately afterwards receives a trigger event telling that a new flow has been initiated and needs to join the same network again.
Current policy control mechanisms typically use an explicit set of tests (conditions to triggers) to decide on a policy and get an enforceable result. Thus, adding more triggers leads to very deep parallel sets of conditionals, and excessively large policy descriptions. Additionally, some of the triggers are dependent on other triggers. E.g., a network cannot be detected on network layer (L3) until the proper interface has been activated on physical layer and detected a link on link layer (L2). Waiting for such dependencies between triggers to be resolved would prevent the terminal from making some other policy decisions in the meantime because of the linear execution of the policy conditionals.
Also, if a linearly executed policy uses only some part of all possible triggers, it is possible that the result causes another trigger event, whose separate linearly executed policy then results in triggers to the first policy. Such looping could be e.g. activation of an interface triggered by a new traffic flow, where that activation could in a second policy result in blocking the use of another interface required for maintaining the traffic flow, which would then nullify reverse the outcome of the first policy.
There is an ongoing effort to define the architecture for 3.9G (3.9th generation) systems. The current view is that there will be a home domain for the users, and their policy information can be transferred to other network domains for proxy policy decision making and enforcement. There will be an Access Aggregation domain through which both the control plane and the user plane of the end user's traffic flows. The domain offers intelligent management of end user access from multiple local Access Connectivity domains, which can be e.g. WLAN (Wireless Local Area Network) or WiMAX (Worldwide Interoperability for Microwave Access) access networks. This facilitates both network based multi-access proxy policy decision and enforcement.
The mobile terminal device should autonomously make decisions about which access networks or access points each data flow should be associated with. However, the terminal may not be able to operate in an optimized way due to insufficient information on local access networks, such as lack of definitions for some access points or inability to detect nearby but yet just out of coverage radio networks.